Miki: a wiki for synchronous modeling of software requirements

Eliciting a high quality requirements model that can be traced down to implementations is a challenge. Keeping models updated for evolving software systems is a further challenge. Formal modelling methods are one approach - but one that is too rigid and costly for many small software engineering companies [1]. We propose a light-weight alternative, using a wiki as the synchronous bridge between requirements capture and more formal modeling features of the IDE such as Eclipse

Using problem descriptions to represent variabilities for context-aware applications

This paper investigates the potential use of problem descriptions to represent and analyse variability in context-aware software products. By context-aware, we refer to recognition of changes in properties of external domains, which are recognised as affecting the behaviour of products. There are many reasons for changes in the operating environment, from fluctuating resources upon which the product relies, to different operating locations or the presence of objects. There is an increasing expectation for software intensivedevices to be context-aware which, in turn, adds further variability to problem description and analysis. However, we argue in this paper that the capture of contextual variability on current variability representations and analyses has yet to be explored. We illustrate the representation of this type of variability in a pilot study, and conclude with lessons learnt and an agenda for further work

Composing features by managing inconsistent requirements

One approach to system development is to decompose the requirements into features and specify the individual features before composing them. A major limitation of deferring feature composition is that inconsistency between the solutions to individual features may not be uncovered early in the development, leading to unwanted feature interactions. Syntactic inconsistencies arising from the way software artefacts are described can be addressed by the use of explicit, shared, domain knowledge. However, behavioural inconsistencies are more challenging: they may occur within the requirements associated with two or more features as well as at the level of individual features. Whilst approaches exist that address behavioural inconsistencies at design time, these are overrestrictive in ruling out all possible conflicts and may weaken the requirements further than is desirable. In this paper, we present a lightweight approach to dealing with behavioural inconsistencies at run-time. Requirement Composition operators are introduced that specify a run-time prioritisation to be used on occurrence of a feature interaction. This prioritisation can be static or dynamic. Dynamic prioritisation favours some requirement according to some run-time criterion, for example, the extent to which it is already generating behaviour

On the structure of problem variability: From feature diagrams to problem frames

Requirements for product families are expressed in terms of commonality and variability. This distinction allows early identification of an appropriate software architecture and opportunities for software reuse. Feature diagrams provide intuitive notations and techniques for representing requirements in product line development. In this paper, we observe that feature diagrams tend to obfuscate three important descriptions: requirements, domain properties and specifications. As a result, feature diagrams do not adequately capture the problem structures that underlie variability, and inform the solution structures of their complexity. With its emphasis on separation of the three descriptions, the problem frames approach provides a conceptual framework for a more detailed analysis of variability and its structure. With illustrations from an example, we demonstrate how problem frames analysis of variability can augment feature diagrams

Are your lights off? Using problem frames to diagnose system failures

This paper reports on our experience of investigating the role of software systems in the power blackout that affected parts of the United States and Canada on 14 August 2003. Based on a detailed study of the official report on the blackout, our investigation has aimed to bring out requirements engineering lessons that can inform development practices for dependable software systems. Since the causes of failures are typically rooted in the complex structures of software systems and their world contexts, we have deployed and evaluated a framework that looks beyond the scope of software and into its physical context, directing attention to places in the system structures where failures are likely to occur. We report that (i) Problem Frames were effective in diagnosing the causes of failures and documenting the causes in a schematic and accessible way, and (ii) errors in addressing the concerns of biddable domains, model building problems, and monitoring problems had contributed to the blackout

Towards explaining rebuttals in security arguments

The satisfaction of software security requirements can be argued using supporting facts and domain assumptions. Sometimes, these facts or assumptions may be questioned, as more knowledge about vulnerabilities becomes available. This results in rebuttals that can be derived from the new information. In this paper, we outline an extension of our OpenArgue tool with an explanation facility that makes a rebuttal more transparent by showing, step by step, why the original security argument does not hold. We achieve this by using the output of the Alligator theorem prover, which constructs explicit and checkable proof objects. We illustrate the feasibility of this approach by applying it to an existing case study of a PIN entry device which involves a security argument that has been rebutted. The output of the prover enables us to unpack the logical reasoning behind the rebuttal at a much greater level of detail. This promises to be useful for argument explanation

Using the event calculus to reason about problem diagrams

Central to the problem frames approach is the distinction of three different descriptions: requirements R, domain assumptions W and specifications S, tied together with the so-called 'frame concern', a proof obligation that has to hold between them if a problem diagram is to be correct: S, W |- R. The form this proof should take is not fixed a priori. It might, however, be desirable to automate it in order to allow for an efficient analysis of large diagrams. To make this possible, we follow some earlier suggestions to use the Event Calculus as a suitable formalism for these descriptions. The main contribution of the present paper is a set of consistency rules as well as guidelines for passing from a problem diagram to its formal description

An aspect-oriented approach to relating security requirements and access control

Affecting multiple parts in software systems, security requirements often tangle with functional requirements. In order to separate crosscutting concerns and increase modularity, we propose to represent security requirements as aspects that can be woven into functional requirements. Using problem frames to model the functional requirements, weaving is achieved by composing the modules representing security aspects with the requirement models. Moreover, we provide guidance on how such security aspects are structured to implement a particular access control solution. As a result, such security aspects become reusable solution patterns to refine the structure of security-related problem

3rd international workshop on advances and applications of problem frames

Michael Jackson's Problem Frames are a highly promising approach to early life-cycle software engineering. Their focus moves the engineer back to the problem to be solved rather than forward to the software and solving a poorly defined problem. By applying the Problem Frames approach, the software engineer can understand the problem context and how it is to be affected by the proposed software, and ultimately work towards the right solution for the problem. The influence of the Problem Frames approach and related work is spreading in the fields of domain modelling, business process modelling, requirements engineering, software architecture as well as software engineering in general